1. Field of the Invention
The present invention relates to the field of on-line catalogs, and more particularly to browse hierarchies that are customized in scope to be substantially coextensive with the scope of each of a number of customized versions of an on-line catalog, the customized browse hierarchies being pared down in scope from a primary hierarchy in accordance with rules-based searches of a central catalog database maintained by the seller.
2. Description of the Related Art
With the advent of Internet based commerce, organizations on both the buy and sell side of business-to-business (B2B) procurement relationships have sought to harness computer networks as a means for automating the procurement process between them. To facilitate e-commerce, and particularly e-procurement, suppliers of goods and services have developed electronic catalogs by which potential buyers can electronically receive and display information regarding the goods and services offered by the supplier, including descriptive information, pictures and prices.
For many reasons, a seller does not often find it desirable to supply the same catalog to all buyers. For instance, a catalog for businesses may be different than a catalog to personal consumers, and catalogs may be different from business to business. The types of computers and peripherals offered to businesses may provide higher performance and as a result are more costly than computer equipment targeted toward consumers. Further, the types of goods and services (i.e. items) marketed to one type of business may differ significantly from those targeted toward another type of business. Moreover, buyers that purchase high volumes of products or services will often negotiate unique pricing agreements with sellers that afford significant discounts compared to lower volume purchasers. Thus, it would be highly desirable from the seller's perspective for each buyer or group of buyers to have their own unique catalog, one that is customized to reflect the individual product/service interests of each customer or customer group, as well their unique business processes and relationships.
For a seller offering many different items (i.e. products or services), maintaining even one version of an e-catalog can be extremely difficult. To maintain several custom versions of an electronic catalog, a physical manifestation of each custom version is typically created and each version must be maintained and updated as the catalog data changes. Each time an item is added, or the attributes or attribute values associated with an item are changed, every physical manifestation of a version of the catalog must be individually updated to ensure that each version reflects the changes in the catalog data. Each version essentially becomes obsolete until updated.
Another issue confronted by sellers offering goods and services for sale over the Internet, whether through electronic catalogs or a web site, is how to present their product and service information in a manner that facilitates efficient browsing by a buyer. The most commonly used technique is to present the information hierarchically to guide the buyer quickly and efficiently to items of interest to the buyer. One hierarchy commonly used by sellers to organize the presentation of items is a “classification-category-vendor” hierarchy. A simple representation of this hierarchy is illustrated in FIG. 1a. Imposing this hierarchy requires that items are explicitly stored in the database along with values for each of these three attributes, or the attributes can be implicitly associated with each item based on the location of the item in the database.
At the classification level 100 of the hierarchy of FIG. 1, catalog items are split into some predetermined number of classes each represented by a unique class label. Each class node is then split at the category level 120 into some number of category nodes equal to the number of predetermined categories established under each class. The category nodes are then split at the vendor level 140 to create some number of vendor nodes under each category equal to the precise number of vendors supplying items in the category.
FIG. 1b is illustrates one possible example of a hierarchy created in accordance with the model of FIG. 1a. In the example, the items in the catalog database are divided into two very general classes: hardware and software. The hierarchy of FIG. 1b reflects these classes with two nodes at the class level 100, one labeled as “hardware” 180 and one labeled as “software” 160. The class nodes are then split at the category level 120 into categories represented by the nodes “O/S (operating systems)” 162, “applications” 164 and “video games” 166. Under the “hardware” node 180, the categories might be “PCs (personal computers)” 182, “peripherals” 186, and “storage” 184. Finally, the nodes at the category level 120 are split at the vendor level 140 according to the particular vendors supplying items from each category as illustrated.
FIG. 1c illustrates the manner in which a seller can then display this hierarchy in the form of hyperlinks on a web page that can be transmitted to a buyer for display on the buyer's computer terminal using web browser software. Typically, the top-level nodes of the hierarchy are displayed first. If a user-buyer selects one of the class nodes, the category nodes are then displayed as a class node in a manner that indicates they are children falling under the class (e.g. indented). Those of skill in the art recognize that there a number of ways in which a user can select hyperlinks, including the positioning of a cursor using a computer mouse and then activating the (i.e. selecting) the node by actuating a button on the mouse. Selection of a category node then causes the child vendor nodes to be displayed under the selected category node. In FIG. 1c, the class node “Software” was selected, which led to the display of category child nodes “Applications,” “O/S” and “Video Games.” The “Applications” node was then selected, leading to the display of child vendor nodes “Adobe,” “Microsoft” and “Intuit.” Selecting the “Adobe” node will typically cause the retrieval from the database and display of all Adobe software application items. This might include a list of part numbers or SKUs, attributes and any descriptive marketing text and images associated with those items.
Under circumstances where a seller is generating custom catalogs for a number of different buyers or buyer groups, it would be preferable to generate custom browse hierarchies for each of the custom versions of the catalog. Each custom browse hierarchy would preferably have a scope that is coextensive with (or at least does not exceed) the scope of items that are included in each custom version of the catalog. For example, if a custom version of a seller's catalog database does not include video game software items, the seller would preferably exclude the “video games” node (and any of its children) from the browse hierarchy of FIG. 1b. Otherwise, the buyer for whom the custom catalog is generated may be confused or annoyed by the existence of a link in the browse hierarchy for which there are no items in the buyer's customized version of the catalog. Thus, it would be preferable for a seller to provide a browse hierarchy for each custom version of the seller's catalog such that the browse hierarchy is itself customized in scope to be substantially coextensive with the subset of catalog items included in that version of the catalog.
Moreover, it would be highly desirable from the seller's perspective if the seller could maintain all catalog data in a central database and in one physical location, and generate customized versions of its catalogs for its various buyers and buyer groups based on the central database. Further, it would be desirable if a custom browse hierarchy could be generated for each custom version of the catalog from a centrally maintained primary browse hierarchy. The primary browse hierarchy would typically (but not necessarily) have a scope that is approximately coextensive with the catalog database. Each custom browse hierarchy would have a scope that is pared down from the primary hierarchy and typically (although not necessarily) coextensive with the scope of its associated custom version of the catalog. Finally, it would be preferable if buyers were coupled to the catalog database through a network, so that the seller could present the customized versions of its browse hierarchies and catalog data to its buyers on a virtual basis. This would eliminate the need to publish and deliver physical manifestations of the customized versions of the catalog and their associated browse hierarchies.